Valstybė ir efektyvumas

Ar dar prisimenate COVID laikus? Atsimenate, kai reikėdavo testų rezultatų ieškoti e. sveikata sistemoje? ESPBI - elektroninės sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacinė sistema galvos skausmą kėlė ne tik gydytojams, pacientams, bet ir laboratorijoms.
Tačiau COVID tyrimai buvo tik pradžia! Sveikatos apsaugos ministerija užsimojo daug plačiau — perkelti visų laboratorinių tyrimų užsakymą į ESPBI IS. Idėja tikrai nėra bloga — pacientui daug paprasčiau ir patogiau, kai tyrimų rezultatus galima rasti vienoje vietoje, o ir gydymo įstaigos nustotų peštis kam priklauso rezultatai ir būtų priverstos jais dalintis. Tačiau yra vienas „bet“…

Visas patogumas, visi privalumai būtų tik tuo atveju, jei ESPBI sistema veiktų greitai, teisingai ir efektyviai. Žodžiai “valstybinė sistema” ir “efektyviai” neturėtų būti naudojami viename sakinyje. Dauguma Lietuvoje veikiančių laboratorijų yra privačios, jos turi savas informacines sistemas, kurios veikia greitai, efektyviai ir dažniausiai teisingai. Ar ESPBI gali pasiūlyti tą patį?

Kas yra laboratorinis tyrimas

Manau visi yra girdėję apie laboratorinius tyrimus, dauguma yra net juos daręsi, tačiau tikriausiai ne visi žino kaip vyksta visas procesas. Tam, kad visi skaitantys tą sužinotų aš jiems dabar ir papasakosiu.

Iš pradžių pacientas ateina pas gydytoją dėl kokių nors problemų. Gydytojas išklauso paciento nusiskundimus ir paskiria laboratorinį tyrimą. Paskyrime yra nurodomas bent vienas tyrimas, daromas iš bent vieno mėginio. Mėginys — tai paciento gabalėlis — ar tai būtų kraujo lašiukas, ar šūdukas, ar sysiukas, skūros, mėsos gabaliukas. Mėsos ir skūros gabaliukai dažniausiai imami patologiniams tyrimams, apie kuriuos čia nerašysiu, nes jie yra sudėtingesni nei įprasti tyrimai. Jeigu tyrimas yra kompensuojamas ligonių kasos, pacientas gali iškarto šoliuoti pas seselę atiduosi dalelę savęs arba jam pasakoma ateiti rytoj iš ryto. Jei tyrimas yra mokamas — prieš tai pacientas turi nueiti į kasą ir susimokėti.

Kai pacientas atsiduria pas seselę-laborantę, ji paima mėginį (šūduko ar sysiuko atveju pacientas pats jį atiduoda). Tada kompiuteryje pažymi, kad mėginys yra paimtas ir išsiunčia laboratorinio tryimo užsakymą į laboratoriją. Mėginys įdedamas į atitinkamos spalvos mėgintuvėlį ir ant jo užklijuojamas barkodas, gautas užsakymo išsiuntimo į laboratoriją metu. Jeigu gydymo įstaiga turi reikalingą įrangą vietoje, o seselė yra kvalifkuota laborantė — iškarto pradeda tyrimo vykdymą. Visgi dažniausiai tyrimai yra atliekami atskirose laboratorijose, su kuriomis gydymo įstaigos yra sudariusios sutartis. Tose laboratorijose darbuotojai gavę užsakymus išsiunčia kurjerį, kuris iš gydymo įstaigos surenka mėginius ir nuveža jiems. Dažniausiai kurjeris yra siunčiamas rytais. Štai kodėl jei kada dareisi tyrimą tau visada sakydavo „ateik rytoj anksti ryte“.

Laboratorijoje mėginiai yra sudedami į analizatorius, tie analizatoriai išanalizavę atiduoda analičių reikšmes ir normas. Analitė — tai koks nors vienas matas, pavyzdžiui kraujo atveju viena analitė yra baltųjų kraujo kūnelių kiekis, kita — raudonųjų kiekis. Iš vieno mėginio galima gauti daug analičių. Norma — tai ribos tarp kurių skaitoma, kad analitės rezultatas yra „sveikas“. Normos priklauso nuo aparato, nes skirtingi aparatai gali tą pačią analitę tirti skirtingais būdais. Net tuo pačiu būdu tiriantys įrengiaiai gali būti skirtingai sukalibruoti. Normos priklauso ir nuo paciento amžiaus bei lyties.

Iš laboratorijų analizatorių surinkti rezultatai ir normos yra suvedami į laboratorijos informacinę sistemą, ten juos patikrina atsakingi laborantai. Esant reikalui — pakoreguoja normas ar užsako pakartojimą, jei aparatas nesąmonę parodė. Jeigu viskas gerai — pasirašo ir pažymi, kad tyrimas atliktas. Laborantai yra atsakingi už tyrimo teisingumą.

Gydymo įstaigos informacinė sistema surenka atliktų tyrimų rezultatus iš laboratorijos informacinės sistemos ir pateikia juos gydytojui. Gydytojas peržiūrėjęs rezultatus sprendžia ar (ir koks) reikalingas tolimesnis paciento gydymas.

Laboratorinių tyrimų užsakymas laboratorijoje

Gyvename IT amžiuje, visos laboratorijos jau seniausiai yra pasidariusios savus elektroninės integracijos sprendimus, per kuriuos gydymo įstaigos gali užsakinėti tyrimus iš savų informacinių sistemų. Didžiausias iššūkis — tai tyrymų klasifikatorių suvienodinimas, nes kiekviena laboratorija turi skirtingus ir keičia juos kada tik užsimano. Tikėkimes sveikatos ministerija šią problemą išspręs, bet nenukrypkime nuo temos apie užsakymą.

Panagrinėkime kaip atrodo standartinis užsakymas, siunčiamas į standartinę laboratoriją. Paprastai yra siunčiama viena užklausa, susidedanti iš šių duomenų:

  • paciento vardas, pavardė — tam, kad jei iškyla kokių nors problemų su tyrimu, gydytojas ir laborantas galėtų susišnekėti apie kurio paciento tyrimą yra kalbama;
  • paciento lytis — kai kurių tyrimų normos priklauso nuo paciento lyties;
  • paciento gimimo data — kai kurių tyrimų normos priklauso nuo paciento amžiaus;
  • gydytojo pastabos laboratorijai;
  • užsakomų tyrimų sąrašas. Paprastai tai tyrimų id sąrašas, kuris yra suderintas su laboratorija iš anksto.

Gali būti ir daugiau laukelių, kiekviena laboratorija reikalauja skirtingos informacijos, pvz kartais perduodamas tyrimą užsakęs gydytojas, kartais skyrius, kuriame užsakytas tyrimas, užsakymo ir mėginio paėmimo datos bei kompensavimo, apmokėjimo duomenys. Kartais reikia atskiros užklausos suderinti mėgintuvėlių spalvas ir barkodus. Tačiau minimalus, tipinis užsakymas susideda iš aukščiau išvardintų punktų, taigi užsakymo JSON atrodytų daugiau mažiau kažkaip taip:

1
2
3
4
5
6
7
8
{
  PatientName: "Vardenis",
  PatientSurname: "Pavardenis",
  PatientGender: "M",
  PatientBirthDate: "2000-01-01",
  Notes: "Atrodė neblogai.",
  Tests: [1001, 1004, 1005]
}

Viskas yra labai paprasta, čia labai sunku ką nors supisti.
— Sunku dar nereiškia, kad neįmanoma! — ryžtingai šūktelėjo sveikatos apsaugos ministerija.

Laboratorinių tyrimų užsakymas e. sveikatoje

Kaip jau tikriausiai supratote iš ryžtingo sveikatos apsaugos ministerijos apsisprendimo viską komplikuoti, laboratorinio tyrimo užsakymas e. sveikatos sistemoje nėra toks tiesmukiškas. Dar mažiau tiesmukiškas jis tampa paanalizavus viešai prieinamą dokumentaciją, skirtą trečiųjų šalių (gydymo įstaigų, laboratorijų, vaistinių) sistemų integracijoms: https://sam.lrv.lt/lt/veiklos-sritys/e-sveikata/reikalavimai-sveikatos-prieziuros-istaigu-ir-vaistiniu-informacinems-sistemoms (pirmas punkas - “Sveikatos priežiūros įstaigų ir vaistinių informacinių sistemų integracijų dokumentacija”).

Nesikabinėsim dėl dokumentacijos paruošimo kokybės, nes yra daugiau nei pakankamai priežasčių prikibti prie pačio laboratorio tyrimo užsakymo proceso. Labai išpūsto proceso, su labai daug besidubliojančių, denormalizuotų duomenų struktūrų. Iš dalies tą išpūtimą galima pateisinti tuo, kad e.sveikata nėra tiesog paprastutė laboratorijos informacinė sistema, bet „viską apimanti“ elektrininių sveikatos įrašų saugykla. Bet viskam yra ribos! Dėl dievo meilės, viskam yra ribos!

Jeigu esi IT specialistas, perspėju, kad tolimesnuose skyriuose bus pateiktas detalus aprašymas kaip yra pateikiamas laboratornio tyrimo užsakymas e. sveikatos sistemoje naudojant jų integracinį tašką. Tai gali sukeltį ūmų psichologinį skausmą! Būtinas išankstinis pasiruošimas.

1. Paciento duomenys

Laboratorijoje pacientas — tik tekstinis laukelis, vardas ir pavardė. E. sveikata — ne laboratorija, ji nori daugiau informacijos arba bent jau sudėtingesniu formatu.

Iš pradžių, jei įmanoma, yra gaunamas jau egzistuojančio paciento resuro ID (RID arba kitaip ESPBI ID). Jei jį įmanoma identifikuoti pagal, pavyzdžiui, asmens kodą, draudžiamojo asmens identifikatorių ar panašiai viskas paprasta. Jei to padaryti neįmanoma, reikia sukurti naują paciento resursą. Šiaip ar taip darysime bent vieną užklausą į e. sveikatos sistemą. Jei naujas pacientas yra užsienietis arba pabėgelis iš Ukrainos, vienos užklausos nepakaks, bet palikime tuos komplikuotus reikalus kitam kartui, šiandien nagrinėjame patį paprasčiausia atvejį.

Sakykime, kad mes žinome paciento asmens kodą, tada galime pasiimti jo e. sveikatos resurso identifikatorių RID:

1
2
3
4
5
6
7
8
GET https://ws-mokymai.esveikata.lt/cxf/Patient/_search?identifier=http://esveikata.lt/Identifier/PersonalCode|50001329999

Gauname atsakymą:
<xml>
  …
  Patient/1000000001/_history/1000000001 <- čia yra RID
  … <- Čia yra papildomų duomenų, tokių kaip vardas pavardė, gimimo metai, EMI numeris, giminystės ryšiai ir pan.
</xml>

Ar mes galime pasiimti visus visus pacientus ir užsikešuoti jų RID, kad daugiau niekada nereikėtų daryti bereikalingų užklausų į e. sveikatą? Ne, nes RID susideda iš pastovosios dalies ir kintamosios — resurso versijos. Užsakant laboratorinius tyrimus ar kuriant bet kokius kitokius dokumentus reikia naujausios pilnos RID versijos. ESPBI tikrina ar paduotas RID yra naujausias ir jei ne — išmes klaidą. Vietoj klaidos išmetimo galėtų tiesiog pati įrašyti naujausios versijos numerį, tačiau kur tame smagumas? Velniop tuos skaičiavimo, tinklo ir elektros resursus! Geriau tegul kiekviena besiintegruojanti sistema prieš kurdama dokumentą iš pradžių išsitraukia pilną paciento resursą su naujausia RID versija, išsiučia jį atgal į ESPBI, kur pati e. sveikata vėl išsitraukia tą patį naujausią RID, vien tam, kad būtų patikrinamas naujumas!

2. Gydytojo duomenys

Kuriant bet kokį dokumentą turi būti paduotas ir pilnas gydytojo RID. Taigi darome dar vieną užklausą — tam, kad išsitrauktumėme naujausią RID. Išsitraukti galime pagal specialisto asmens kodą, darbovietę ar panašiai, bet tikslingiau išsisaugoti RID pastoviąją dalį, pagal ją gauti pilną resursą, kuriame yra ir kintamoji dalis:

1
2
3
4
5
6
7
8
GET https://ws-mokymai.esveikata.lt/cxf/Practitioner/1000000002

Gauname atsakymą:
<xml>
  …
  Practitioner/1000000002/_history/1000000002
  …
</xml>

Taip, ši užklausa vėl neišvengiamas tinklo resursų švaistymas vien dėl to, kad ESPBI negali automatiškai dokumentuose užpildyti RID kintamosios dalies, nors ir išsitraukia tą dalį atlikdami duomenų validavimą.

3. Gydymo įstaigos duomenis

Taip, kaip paciento bei gydytojo atveju — turime išsitraukti ir gydymo įstaigos pilną identifikatorių:

1
2
3
4
5
6
7
8
GET https://ws-mokymai.esveikata.lt/cxf/Organization/1000000003

Gauname atsakymą:
<xml>
  …
  Organization/1000000003/_history/1000000003
  …
</xml>

4. Aspilankymas

Kai jau turime gydytojo, gydymo įstaigos ir paciento RID, turime pacientui užregistruoti vizitą, kurį e. sveikata vadina Encounter. Nors laboratorijai visiškai nesvarbu kada pacientas lankėsi pas gydytoją kai buvo padarytas laboratorinio tyrimo užsakymas, e. sveikata mano kitaip.

Turime daryti dar vieną užklausą apsilankymo sukūrimui. Bet šį kartą į vieną užklausą sudėsime jau nebe vieną, o du dalykus: vizito dokumentą ir dokumentą, kuriame įrašyta, kad kuriamas vizito dokumentas (Provenance). Taigi užklausa susideda iš maždaug tokių duomenų, kuriuos užrašiau nevisai xml formatu, o sutraukiau dėl skaitomumo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<xml>
  Provenance:
    target: EncounterID,
    recorded: new DateTime(),
    EventType: 1, <- "1" reiškia "Atvykimas į SPĮ gauti ambulatorinių paslaugų"
    EventTypeName: Atvykimas į SPĮ gauti ambulatorinių paslaugų, <- Taip, būtina siūsti tiek kodą, tiek kodo reikšmę…
    Author: Practitioner/1000000002/_history/1000000002,

  Encounter:
    IsInsured: boolean,
    InsuranceAssertedAt: new DateTime(),
    PatientEmiNumber: 'patient-00001-00001',
    ServiceType: 'other',
    ServiceTypeName: 'Kita',
    Status: 'in progress',
    Class: 'ambulatory',
    Patient: Patient/1000000001/_history/1000000001,
    CreatedByDoctor: Practitioner/1000000002/_history/1000000002,
    VisitDoctor: Practitioner/1000000002/_history/1000000002,
    ServiceProvider: Organization/1000000003/_history/1000000003
</xml>

Atsakyme gauname abiejų sukurtų dokumentų RID.

Įdomus pastebėjimas dėl klasifikatorių: nors siunčiame kodus tokius, kaip EventType, bet būtina siųsti ir to kodo tekstinę reikšmę — EventTypeName. ESPBI tikrina ar reikšmė nurodyta teisingai ir išmes klaidą, jei ji skirsis nuo oficialaus klasifikatoriaus. Labai įdomu kodėl taip padaryta, negi klasifikatorių reikšmės yra saugomos duomenų bazėje? Hmm… Skamba kaip duomenų bazės vietos švaistymas… Taip pat turi būti paduodamas tiek paciento RID, tiek jo EMI (elektroninės medicininės istorijos) numeris. Negi yra naudojama dokumentinė duomenų bazė, todėl nėra galimybės saugoti realiacinius ryšius? Tai paaiškintų ir kodėl būtina nurodyti tiek resurso ID, tiek jo reikšmes.

5. E025 — ambulatorinio apsilankymo aprašymas

Kai jau sukurtas apsilankymas (Encoutner), galima kurti ir to apsilankymo ambulatorinį aprašymą. E. sveikatai neužtenka žinoti vien tik kada, kur ir pas ką pacientas apsilankė. Ji dar nori žinoti kodėl. Dažnu atveju tas “kodėl” apsiriboja tik diagnozės kodu, bet specialistui yra suteikiama galimybė plėstis kiek tik nori ir pildyti visokias anamnezes, būklės įvertinimus, alergijas ir panašiai.

Būkim biedni, bet teisingi — gydytojai yra užsiėmę, nenori jie dirbti rašytojais. Jie nori tik užsakyti bendrą kraujo tyrimą tam vargšui pacientui. Užpildys jie tik tai kas būtina, vienintelį privalomą lauką — diagnozės kodą. Bet net jei tai ir yra vienintelis būtinas laukas gydytojui, ar tai yra vienintelis būtinas laukas e. eveikatos sistemai? O, ne ne ne!

Pats trumpiausias ambulatorinis aprašymas (E025 forma), kuriame naudinga informacija yra tik diagnozės kodas ir laboratorinio tyrimo užakymo užsakymas (Order), susideda iš dvylikos dokumentų:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
<xml>
  Provenance [id = 1]:
    target: CompositionID,
    recorded: new DateTime(),
    EventType: 2,
    EventTypeName: Ambulatorinės gydymo paslaugos suteikimas (apsilankymas),
    Author: Practitioner/1000000002/_history/1000000002,

  Composition [id = 2]:
    Date: new DateTime(),
    Type: 34108-1,
    TypeName: Ambulatorinio apsilankymo aprašymas,
    Status: preliminary,
    Confidentiality: N, <- visada turi būti N. Nieko nereiškia
    Custodian: Organization/1000000003/_history/1000000003, <- Gyd. įstaigos RID
    AuthorDepartment: Organization/1000000003/_history/1000000003, <- Gyd. įstaigos arba filialo RID
    Author: Practitioner/1000000002/_history/1000000002
    AuthorQualification: 221104, <- iš Practitioner/1000000002 resurso, gydytojas gali turėti kelias kvalifikacijas, čia nurodoma viena jų
    AuthorQualificationName: Medicinos gydytojas,
    Encounter: Encounter/1000000004/_history/1000000004,
    Subject: Patient/1000000001/_history/1000000001,
    Event: Provenance/1,
    EventType: 2,
    EventTypeName: Ambulatorinės gydymo paslaugos suteikimas (apsilankymas),

    Sections:
      Code: 55752-0
      Name: Medicininiai duomenys
      {
        Code: 11348-0
        Name: Anamnezė
        Reference: Observation/3

        Code: 8716-3
        Name: Būklės įvertinimas
        Reference: Observation/4

        Code: 56851-9
        Name: Tyrimų / konsultacijų planas
        {
          Code: 18776-5
          Name: Tyrimų / konsultacijų planas
          Reference: List/6

          Code: 56447-6
          Name: Tyrimų / konsultacijų plano aprašymas
          Reference: Observation/8
        }

        Code: 11535-2
        Name: Diagnozės
        Reference: List/9

        Code: 55753-8
        Name: Taikytas gydymas
        {
          Code: 62387-6
          Name: Taikyto gydymo aprašymas
          Reference: Observation/11
        }

        Code: 39221-7
        Name: Gydymo, slaugos, darbo, ambulatorinės priežiūros rekomendacijos
        {
          Code: 39223-3
          Name: Gydymo, slaugos, darbo, ambulatorinės priežiūros rekomendacijos
          Reference: Observation/12
        }
      }

  Observation [id=3]
    Code: 11348-0
    Name: Ligos anamnezė
    Text: -, <- arba tai, ką įrašė gydytojas arba jeigu nieko neįrašė, tiesiog "-"
    Date: new DateTime(),  <- Tas pats, kaip ir Composition resurse
    Status: final,  <- gali būti "final" arba "cancelled"
    Reliability: "ok", <- visada "ok"
    Subject: Patient/1000000001/_history/1000000001, <- Tas pats, kaip ir Composition resurse
    Performer: Practitioner/1000000002/_history/1000000002,  <- Tas pats, kaip ir Composition resurse

  Observation [id=4]
    Code: 8716-3
    Name: Gyvybiniai požymiai
    Date: new DateTime(),
    Status: final,
    Reliability: "ok",
    Subject: Patient/1000000001/_history/1000000001,
    Performer: Practitioner/1000000002/_history/1000000002,
    Related: Observation/5

  Observation [id=5]
    Code: 12132-7
    Name: Kita būklės įvertinimo informacija
    Text: -,
    Date: new DateTime(),
    Status: final,
    Reliability: "ok",
    Subject: Patient/1000000001/_history/1000000001,
    Performer: Practitioner/1000000002/_history/1000000002,

  List [id=6]
    Code: 18776-5
    Name: Tyrimų / konsultacijų planas
    Entries: [Order/7]

  Order [id=7]
    SourceQualification: 221104,
    SourceQualificationName: Medicinos gydytojas,
    Type: 2
    TypeName: Laboratorinio tyrimo užsakymo (siuntimo) skyrimas
    SpecimenType: 28,
    SpecimenTypeName: Tepinėlis iš nosiaryklės,
    DiagnosticItemCode: 773,
    DiagnosticItemCodeName: Bendro baltymo koncentracijos nustatymas,
    Date: new DateTime(),
    Subject: Patient/1000000001/_history/1000000001,
    Source: Practitioner/1000000002/_history/1000000002,
    Detail: Encounter/1000000004/_history/1000000004

  Observation [id=8]
    Code: 56447-6
    Name: Gydymo plano pastabos
    Text: -,
    Date: new DateTime(),
    Status: final,
    Reliability: "ok",
    Subject: Patient/1000000001/_history/1000000001,
    Performer: Practitioner/1000000002/_history/1000000002,

  List [id=9]
    Code: 11535-2
    Name: Diagnozių sąrašas
    Entries: [Condition/10]

  Condition [id=10]
    Date: new DateTime(),
    DiseaseType: 0,
    DiseaseTypeName: Kitos ligos, pakartotinai diagnozuojamos šiais metais,
    Subject: Patient/1000000001/_history/1000000001,
    Encounter: Encounter/1000000004/_history/1000000004,
    Asserter: Practitioner/1000000002/_history/1000000002,
    Code: Z00.0,
    CodeName: Bendras medicininis ištyrimas,
    Status: confirmed

  Observation [id=11]
    Code: 62387-6
    Name: Intervencijų aprašymas
    Text: -,
    Date: new DateTime(),
    Status: final,
    Reliability: "ok",
    Subject: Patient/1000000001/_history/1000000001,
    Performer: Practitioner/1000000002/_history/1000000002,

  Observation [id=12]
    AuthorQualification: 221104,
    AuthorQualificationName: Medicinos gydytojas,
    Code: 39223-3
    Name: Diagnozės rekomendacijos, aprašymas CPHS
    Text: -,
    Date: new DateTime(),
    Status: final,
    Reliability: "ok",
    Subject: Patient/1000000001/_history/1000000001,
    Performer: Practitioner/1000000002/_history/1000000002,
</xml>

Visi viršuje išvardinti duomenys yra tikrai siunčiami ir yra tikrai būtini, norint teisingai užpildyti E025 formą e. sveikatoje. Tokia yra realybė šiandien.

Jeigu pažiūrėjai atidžiau, pamatei, kad dauguma laukų dubliuojasi, yra pridėta bereikalingų ryšių, dalis ryšių yra denormalizuoti. Pašalinus visą triukšmą užklausa atrodytų maždaug taip:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<xml>
  Composition:
    Date: new DateTime(),
    Type: 34108-1,
    AuthorDepartment: Organization/1000000003/_history/1000000003,
    Author: Practitioner/1000000002/_history/1000000002
    AuthorQualification: 221104,
    Encounter: Encounter/1000000004/_history/1000000004,
    Diagnoses: [
      {
        DiseaseType: 0,
        Code: Z00.0,
      }
    ],
    Orders: [
      {
        Type: 2,
        SpecimenType: 28,
        DiagnosticItemCode: 773,
        SourceQualification: 221104,
      }
    }
</xml>

Bet juk ESPBI yra rimta, sudėtinga sistema, kuriai būtina pateisinti tuos milijonus eurų, paaukotų jos kūrimui. Ar už 23 eilutes kad nors mokėtų milijoną? Tikrai ne! O už 167? Jau tikrai atsiratų kandidatų!

Kad ir kaip ten bebūtų, prisideda dar viena užklausa į e. sveikatą, nes be laboratorinio tyrimo užsakymo užsakymo (Order/7/_history/xx) neįmanoma užpildyti E200 formos — laboratorinio tyrimo užsakymo.

6. E200 — laboratorinio tyrimo užsakymas

Kai jau turime apsilankymą ir apsilankymo ambulatorinį aprašymą, kuriame yra laboratorinio tyrimo užsakymo užsakymas, galime pradėti formuoti ir patį laboratorinio tyrimo užsakymą. Tai dar viena užklausa su 5 naujais dokumentais plius jau egzistuojančiu Order:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<xml>
  Provenance [id = 1]:
    target: CompositionID,
    recorded: new DateTime(),
    EventType: 3,
    EventTypeName: Laboratorinio tyrimo užsakymo (siuntimo) sukūrimas,
    Author: Practitioner/1000000002/_history/1000000002,

  Composition [id = 2]:
    Date: new DateTime(),
    Type: X-LAB-ORDER,
    TypeName: Laboratorinio tyrimo užsakymas,
    Status: final,
    Confidentiality: N,
    Custodian: Organization/1000000003/_history/1000000003,
    AuthorDepartment: Organization/1000000003/_history/1000000003,
    Author: Practitioner/1000000002/_history/1000000002
    AuthorQualification: 221104,
    AuthorQualificationName: Medicinos gydytojas,
    Encounter: Encounter/1000000004/_history/1000000004,
    Subject: Patient/1000000001/_history/1000000001,
    Event: Provenance/1,
    EventType: 3,
    EventTypeName: Laboratorinio tyrimo užsakymo (siuntimo) sukūrimas,

    Sections:
      Code: 57139-8,
      Name: Bendrosios medicinos siuntimo aprašymas,
      Reference: Order/7/_history/xxx,

      Code: 65842-7,
      Name: Priėmimo būsena,
      Reference: OrderResponse/3,

  OrderResponse [id=3]
    Date: new DateTime(),
    Request: Order/7/_history/xxx,
    Code: "accepted",
    Who: Practitioner/1000000002/_history/1000000002

  Order [id=Order/7/_history/xxx]
    SourceQualification: 221104,
    SourceQualificationName: Medicinos gydytojas,
    Type: 2
    TypeName: Laboratorinio tyrimo užsakymo (siuntimo) skyrimas
    SpecimenType: 28,
    SpecimenTypeName: Tepinėlis iš nosiaryklės,
    DiagnosticItemCode: 773,
    DiagnosticItemCodeName: Bendro baltymo koncentracijos nustatymas,
    Date: new DateTime(),
    Subject: Patient/1000000001/_history/1000000001,
    Source: Practitioner/1000000002/_history/1000000002,
    Detail: Encounter/1000000004/_history/1000000004
    Detail2: DiagnosticOrder/4

  DiagnosticOrder [id=4]
    Subject: Patient/1000000001/_history/1000000001,
    Orderer: Practitioner/1000000002/_history/1000000002,
    ClinicalNotes: -
    Status: requested,
    Code: 773
    CodeName: Bendro baltymo koncentracijos nustatymas
    Specimen: Specimen/5

  Specimen [id=5]
    RegistrationCode: text,
    Date: new DateTime(),
    Type: 28,
    TypeName: Tepinėlis iš nosiaryklės,
    Subject: Patient/1000000001/_history/1000000001,
    StorageTransportationDetails: 1
    StorageTransportationDetailsName: Kambario temperatūroje,
</xml>

Palyginus su E025 čia visko daug mažiau. Trumpai rašant čia yra:

  1. sukuriamas DiagnosticOrder ir įdedamas į E025-tos formos Order’į. Jame įrašomos pastabos laborantui ClinicalNotes;
  2. nurodomas registracijos kodas RegistrationCode;
  3. nurodoma laikymo, gabenimo informacija StorageTransportationDetails.

Ar tam tikrai reikia užklausos, kurioje yra 6 dokumentai? Manau įmanoma sugalvoti ką nors paprasčiau…

7. Pasirašymas

Tik nesakykite, kad buvote tokie naivūs manydami, kad užtenka tik sukurti ir išsiųsti į e. sveikatą E025 ir E200 formas? Ir laboratorinio tyrimo užsakymas bus baigtas? Laboratorija galės siųsti savo kurjerį mėginiui paimti? Tai būtų pernelyg paprasta! Prieš formoms oficialiai įsigaliojant jos turi būti pasirašomos.

Iš pradžių reikia sugeneruoti pasirašymo nuorodą. Tą mums su džiaugsmu padarys ESPBI, tereikia atlikti dar vieną užklausą!

1
2
3
4
GET https://ws-mokymai.esveikata.lt/cxf/Documents/sign?id=E025CompositionID,E200CompositionID

Atsakymas:
  https://ws.gosign.lt/unisignes/ui/000000001/0abcdef01234567890001/main?locale=lt

Specialistas, atidaręs tą nuorodą pasirašo PDF failus, kuriuos pati ESPBI sugeneruoja iš mūsų siųstų duomenų. Kai pasirašymas pabaigiamas, reikia išsiųsti dar vieną užklausą į ESPBI, kuri pažymi, kad gydytojas tikrai jau pasirašė:

1
GET https://ws-mokymai.esveikata.lt/cxf/Documents/sign/000000001/confirm

Negi jau viskas?

Taip, jau viskas. 8 užklausos, kuriomims ištraukti 3 ir naujai sukurta 19 dokumentų. Vienam laboratorinio tyrimo užsakymui, kuriame užsakomas vienas tyrimas. Toks įspūdis, kad sistemą projektavo buhalteris. Privačioms laboratorijoms pakanka vienos užklausos. Reikia turėti neeilinų sugebėjimų, kad sugalvotum kaip vieną užklausą paversti į 8 užklausas su 19 dokumentų.

E. sveikata galėtų savo tituliniame puslapyje užsirašyti:

Bent aštuonis kartus daugiau užklausų ir devyniolika kartų daugiau dokumentų lyginant su kitomis sistemomis!

Nieko nuostabaus, kad jie nuolat turi greitaveikos problemų. Tikriausiai turės problemų ir su talpinimo vieta, nes jau dabar giriasi, kad turi 200 TB duomenų. Jeigu normaliai būtų susikodinę kažin ar terabaitą išnaudotų…